overviewControls: Limit Dash height to 15% of the overview's
Back when the Dash was vertical, the size of each item was calculated
solely based on the available height. After making the Dash horizontal,
this was swapped by the available width. However, when the height of the
Dash decreases, the current code results in never scaling them up ever
again.
Fix that by making ControlsManagerLayout explicitly pass the maximum Dash
sizes. Remove the 'notify::width' handler that served the same purpose.
Remove the dummy applications page that was introduced as a temporary
step. Replace the 'page-changed' and 'page-empty' signals with a 'search-active'
boolean property.
Remove ViewSelector.ViewsPage since it's now unused, and all the page handling
mechanism. At last, since we don't use any ShellStack features anymore, simply
make it a St.Widget with a ClutterBinLayout as the layout manager.
Jonas Dreßler [Tue, 9 Feb 2021 11:51:33 +0000 (12:51 +0100)]
screenshot: Fix slow audiovisual feedback on when taking screenshot
Add a "screenshot-taken" signal from the screenshot service's internal C
implementation, and use that to trigger the camera flash visual effect
and the click sound, allowing them to run in parallel with the PNG
compression instead of waiting until the file is complete to start.
This significantly improves perceived latency on high res setups such as
4K, 5K, or dual 4K screens.
Jonas Dreßler [Thu, 11 Feb 2021 17:30:10 +0000 (18:30 +0100)]
screenshot: Replace template strings with .format()
CI will complain when we add screenshot.js to the POTFILES in the next
commit because gettext doesn't like template strings, so make CI happy
and switch to .format() instead.
Brion Vibber [Wed, 18 Dec 2019 22:34:45 +0000 (14:34 -0800)]
Fix for screenshots when pictures path is unavailable
On my local jhbuild setup some local stuff is not set up and
there's no pictures folder. This fixes a regression where it
blew up instead of saving to the home dir in this situation.
workspace: Always leave overview when in app grid state
The behavior of workspaces is different depending on whether
the overview is in window picker state, or app grid state.
When in window picker state, clicking on adjacent workspaces
should only activate them, without hiding the overview; and
clicking on the active workspace hides the overview. When in
app grid state, clicking on a workspace must always hide the
overview.
Pass the overview adjustment to Workspace, and leave overview
if the overview state is bigger than WINDOW_PICKER.
workspacesView: Interpolate against relative workspace boxes
The overview transition consists of getting the initial and final
states of the overview adjustment, derivating various other internal
states from them (such as the fit mode, opacities, translations, etc),
and finally interpolating the allocation boxes.
When interpolating between the fit mode, WorkspacesView uses the current
allocation box to derivate the SINGLE and ALL fit mode boxes. However,
that creates a curved path during overview transitions. What we really
want to do here is calculate the fit mode box relative to the corresponding
overview state. For example:
+----------------+----------+------------------------+
| Overview State | Fit Mode | Workspaces geometry |
+----------------+----------+------------------------+
| HIDDEN | SINGLE | Cover entire screen |
| WINDOW PICKER | SINGLE | Between minimap & Dash |
| APP GRID | ALL | 15% screen height |
+----------------+----------+------------------------+
Using the table above as the reference, when the overview transitions
between WINDOW PICKER and APP GRID, we must interpolate between
(SINGLE fit mode @ between minimap & Dash) and (ALL fit mode @ 15% screen
height). That way, we always interpolate the final boxes, which corrects
the odd path that workspaces follow during this transition.
Make the WorkspacesView of the primary monitor use these cached boxes
when the overview is in the middle of a transition, and the fit modes of
the initial and final state differ, to calculate the workspaces positions.
workspacesView: Use calculated workspace state for progress
It works just like before, except that this has the nice side effect
of not changing the workspace mode when leaving the overview from
the app grid state.
Move AppDisplay, WorkspacesDisplay, and ThumbnailsBox from ViewSelector to
ControlsManager. This allows to always allocate the correct size for AppDisplay,
and will enable for a plethora of further improvements. The end goal is to
completely remove ViewSelector, and let ControlsManager handle the layout of
everything that's visible in the overview.
For now, replace the apps page with a dummy actor in ViewSelector.
Adjust various callers around the codebase to not access the ViewSelector
directly from the overview anymore.
Bind the opacity of the primary workspace to WorkspaceDisplay's opacity. This
allows removing the parent opacity hack in place, which will be done by the
next commit.
viewSelector: Move 'toggle-applications-view' to ControlsManager
Move the shortcut handling into ControlsManager, and reimplement
the callback in such a way that it behaves correctly with the
current overview machinery.
Now that Overview is able to ease into any state, be it window
picker or app grid, we can move this ViewSelector method to
Overview itself, which is its rightful place to live.
Remove ViewSelector.showApps(), and make all callers call
Main.overview.show(ControlsState.APP_GRID). Also make sure the
show apps button is correctly toggled.
overivew: Propagate target state when animating to overview
Next commits will requires ControlsManager to animate to different
states, depending on how Overview is called. Add a new 'state'
parameter to ControlsManager's, and OverviewActor's animateToOverview,
and Overview.show().
Remove Workspace.zoomTo/FromOverview(), they're unused now. Rename
everything up to ControlsManager to prepareToEnter/LeaveOverview(),
since these classes don't run the animation anymore.
workspacesView: Derive workspace mode from overview state
WorkspacesView uses the floating layout when the overview is in window
picker mode, and the session layout when the overview is in app grid
mode. Up until now, the fit mode adjustment was used to derive the
workspace mode, but it is incomplete as it doesn't have the full range
of workspace states.
Make ViewSelector cascade the overview adjustment to WorkspacesDisplay,
and use the overview adjustment itself to derive the workspace mode.
Extra workspaces don't have to account for the fit mode, and thus are
basically a clamp(state, 0, 1) of the overview state. However, don't
call animateTo/FromOverview() anymore, since they ease the workspace
mode adjustment.
Florian Müllner [Fri, 26 Jun 2020 16:38:28 +0000 (18:38 +0200)]
workspacesView: Add primary view to workspaces display
Boy, does this commit feel good.
While the workspaces view on the primary monitor *appears* as part of
the overall overview hierarchy, this hasn't actually been the case
until now. We synchronized its size and (stage) position to match
the workspaces display, but actually kept in a separate layer for
the transitions to and from the overview.
But now that the new layout manager slides out completely during the
overview transitions, the workspaces display starts out covering the
entire work area, which is exactly what we need for the transition.
So finally stop faking it, and actually make the primary workspaces
view a child of the workspaces display.
overviewControls: Ease main adjustment when animating to/from overview
Instead of delegating it to ViewSelector, make the transition to and from
overview ease the main state adjustment.
This commit temporarily breaks these animations, but on the other hand
introduces an important feature: ViewSelector is always allocated to the
actual size. This will finally allow for adding WorkspacesView as a child
of WorkspacesDisplay, and finally remove the actual geometry hack, which
is what next commit is about.
Instead of directly accessing ViewSelector and calling these methods
there, cascade the calls to OverviewActor, ControlsManager, and finally
ViewSelector. Also move the opacity transition to OverviewActor.
Currently, ActivitiesContainer reacts to showAppsButton and
transitions between app grid and window picking states on
its own. In the future, we want full control over this.
ControlsManager already has a state adjustment that represents
all possible overview states. Propagate this adjustment up to
ActivitiesContainer, and use it to drive the transition.
This requires moving the callback to the showAppsButton to
ControlsManager, since now it control the state adjustment
itself, not ActivitiesContainer's adjustment.
overviewControls/controlsManager: Use a custom layout manager
In the future, we want to tightly control the state of the
layout throught gestures, which requires hooking everything
together with adjustments. This is the first step in this
direction.
Add a new custom layout manager for ControlsManager that
allocates the search entry, the view selector, and the Dash,
vertically.
Pascal Nowack [Thu, 11 Feb 2021 14:17:22 +0000 (15:17 +0100)]
ui/windowManager: Fix horizontal scrolling when smooth events are used
Currently, gnome-shell uses the wrong scrolling direction for
horizontal scrolling events.
When dx < 0 for a smooth scroll event, then the scrolling direction is
supposed to be Clutter.ScrollDirection.LEFT, instead of
Clutter.ScrollDirection.RIGHT, as dx is smaller than 0.
Fix this issue by swapping the values LEFT and RIGHT.
Florian Müllner [Tue, 9 Feb 2021 23:10:03 +0000 (00:10 +0100)]
polkitAgent: Ensure cleanup if dialog wasn't shown
It is possible for an initiated session to complete without
a request if polkit can authenticate the action without user
input. We fail to clean up after ourselves in that case, as
the cleanup is done after the dialog is closed.
The dialog can still be shown when the code that hides existing
dialogs while the screen is locked shows it on unlock. But as
the session was closed, the dialog is now defunct and cannot
be dismissed by the user.
Fix this by running the cleanup on close() when the dialog
wasn't shown.
Florian Müllner [Tue, 9 Feb 2021 18:57:55 +0000 (19:57 +0100)]
dash: Re-fittsify
Now that the dash is no longer attached to a screen edge, it lost
its "infinite width" (Fitts' law). Restore it by moving the visible
bar into a separate layer underneath the actual icons, extend the
icons to the bottom edge, and replace the margin around the dash
with padding inside the icons.
Jakub Steiner [Thu, 4 Feb 2021 13:16:00 +0000 (14:16 +0100)]
stylesheet: Increase app dropshadows
Increase the app icon dropshadow to separate the icon from the window thumbnail.
The shadow change is global, but due to perfomance implications, the icon-dropshadow
class is only used on the thumbnail view.
Florian Müllner [Tue, 9 Feb 2021 20:48:39 +0000 (21:48 +0100)]
dash: Consider additions for separator visibility
The children variable holds the icons that were originally in
the dash. For the separator visibility, we should consider the
icons that are in the dash after the update, so we must consider
additions as well as removals.
loginDialog: Fill UserListItem layout to show the timed login indicator
When the timed indicator is shown the UserListItem layout should fill
so that the timed indicator can expand to use the whole item space.
So, always use the default value for x-align that will make it to fill
the available space without causing any regression when the timed
indicator is hidden.
Previously we used a bunch of heuristics for this. We checked if velocity
was directed towards the nearest snap point and its value was larger than
a threshold. If it is, we completed the swipe, otherwise we cancelled it.
This was good enough at the time, because this code was originally written
for back/forward swipe. Since then, the swipe tracker was extended to
handle arbitrary snap points and not just 0 and 1, or -1 and 0, depending
on text direction. After that it was iterated on, but never significantly
redone.
This worked well enough, but had two problems:
1. In some cases, notably overview, it may be wanted to be able to swipe
through multiple pages at once. This wasn't really possible because we
always picked the adjacent snap point.
2. Since we can't do that well, we want to restrict swipes to one page at a
time. It was done in a rather hacky way by clamping the position into
[-1, 1] range from the place where we started the swipe. This works
if we start the swipe from idle position, but if an animation was
already going, the range would be clamped to arbitrary values, and very
likely containing only one snap point, which we already swiped past at
this point. In this case, finishing the swipe would cancel it regardless
of velocity. This means that if one tries to quickly move through
carousel pages via swiping, half of the swipes will be inexplicably
cancelled.
We'll use the deceleration formula from
https://medium.com/@esskeetit/how-uiscrollview-works-e418adc47060#10ce
to calculate then projection point, then pick the nearest snap point and
calculate the duration as we did before. It works well enough for short
distances, but has two problems:
1. It caps the maximum distance at a pretty low value - about 5 pages in my
testing.
2. With how we pick the nearest snap point, it's too easy to accidentally
cancel the swipe,
To combat the first problem, we can modify the curve: only use linear
function at small distances, and smoothly transition it to a parabola
further.
For the second problem we can add two special cases: first, if the swipe
ended up between the initial snap point and the next one, we always prefer
the latter. Second, a good old velocity threshold for cancelling.
We'll also use a slightly smaller deceleration value for touchpad: 0.997
instead of 0.998.
Now that we can pick any snap point, the [-1, 1] clamping doesn't make
sense anymore, so instead let's replace it with a more flexible
mechanism: if we're near a snap point, pick its adjacent snap points.
Otherwise, take the two nearest snap points, and take their adjacent
snap points. This way we have 3 snap points to choose from when
starting a swipe from an idle position, and 4 if we start during an
ongoing transition.
This way, if we've just swiped from snap point n to n+1, the transition
will pick snap points n-1, n, n+1, n+2 and if we swipe again, we will
likely land on n+2. During that transition, if we swipe again, it will
likely have already passed the snap point n+1, so this time the available
snap points will be n, n+1, n+2, n+3, so we can swipe again and it will
still complete, and so on.
This will make it easy to allow multi-page swipes as well, by just
removing the clamping.
swipeTracker: Calculate velocity using scroll history
In some cases we may get anevent with very low delta at the end of the
swipe. While we can't completely ignore them, we can smooth them using a
scroll history, similarly to what GTK kinetic scrolling does: keep track
of the last 150ms of events, and sum their deltas when calculating the
velocity.
The logic is based on what GTK does in GtkGestureSwipe and
GtkEventControllerScroll.
Razze [Sat, 30 Jan 2021 19:10:03 +0000 (20:10 +0100)]
fingerprint: Use makeProxyWrapper for fprintManager
The reason this wasn't using the Gio.DBus.makeProxyWrapper() convenience API is that it passes custom flags to the proxy, and that wasn't supported by the wrapper at the time.
As this is now possible, this commit migrates us to the new API.
Florian Müllner [Sun, 7 Feb 2021 22:21:55 +0000 (23:21 +0100)]
st: Test for :insensitive styling
Commit 473e77e2c5a fixed applying the :insensitive pseudo class to
initially unreactive widgets, and adjusted the style test to work
with that.
In hindsight, we can do better than just making the test work, and
include a test case for the :insensitive styling as well (namely
the issue the previous commit was fixing).
If the input is empty, there’s no point in adding it to the history –
it’ll just be mildly annoying when the user has to skip past it next
time they consult the history.
Let empty input result in an error, just like other invalid commands
(bad syntax, nonempty whitespace, etc.). GLib already has an error
message “Text was empty (or contained only whitespace)” which it shows
for whitespace-only input, so letting that message apply also to empty
input makes sense.
This requires some tweaks further down the file to avoid interpreting
empty input as an empty path (relative to the home directory) and then
opening the home directory.
Part of https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3183.
Florian Müllner [Sun, 7 Feb 2021 22:21:55 +0000 (23:21 +0100)]
st/widget: Fix applying :insensitive to initially unreactive widgets
We are applying the :insensitive pseudo class to unreactive widgets,
or at least we are supposed to. As we currently only update the style
on notify, we don't apply it to initially unreactive widgets.
This was covered up partially until recently when Clutter started to
use G_PARAM_EXPLICIT_NOTIFY. Before that, the notify handler would run
when explicitly setting :reactive to FALSE at construction time.
Make sure we always apply the pseudo class correctly by updating it
after construct properties have been set.
st/theme-node-drawing: Fix inner shadow fast path condition
We want to use the fast path of filling the entire area if either the
left and right shadows would overlap or the top and bottom shadows. The
latter check was wrong due to a typo resulting in the regular path
being used in some cases it couldn't (and shouldn't) handle.
This was causing the inset shadow used to highlight panel buttons to
not appear for buttons above a certain width.
Bastien Nocera [Fri, 5 Feb 2021 14:33:00 +0000 (15:33 +0100)]
data: Fix grammar and wording in new GSettings key
The description for the 'welcome-dialog-last-shown-version' key
must have been written quite late in the day, as it's full of grammar
mistakes, typos and British English.
*sips coffee*
I can say that, because I wrote it.
*sips coffee*
Anyway, that might be a bit better.
*sips coffee* and Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1641
Florian Müllner [Thu, 4 Feb 2021 23:17:12 +0000 (00:17 +0100)]
data: Move custom close icon into actions/
Adwaita uses ui/ for the corresponding icon, but GTK treats icons
from a resource path as part of the hicolor theme that doesn't
have such a subdir. And as GTK determines subdirs by enumerating
the theme directory, any subdirs that only exist in the resource
are ignored, whoops.
Make sure the icon can be found by moving it to a standard subdir.
theme: Scale media player button padding with font size
The total width of the MediaMessage scales with the font size, but the
padding of the media player buttons do not, which can become an issue
with text-scaling-factor < 1.
mpris: Hide unused elements to leave more space for the title
The Message class this is derived from unconditionally adds a close
button with 0 opacity that only gets shown on hover for messages that
can actually be closed. The MPRIS MediaMessage however can never be
closed and having a close button can cause the title to be cut short
unexpectedly.
Similarly the secondary text which other notifications use to display
the notification time is always left empty here as well.
appDisplay: Do not bind popdown call to grabHelper onUngrab
grabHelper is passing a boolean argument to onUngrab() callback function
and since commit 1acbdcc9b3b0 we'd end up adding it to to the callback list or
we'd try to invoke it:
(gnome-shell:3490851): Gjs-CRITICAL **: 17:19:20.460: JS ERROR:
TypeError: func is not a function
onComplete/<@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:56
onComplete@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:40
_makeEaseCallback/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:85:13
_easeActor/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:170:64
Use an arrow function so that we can control the parameters we pass
to popdown.
Razze [Tue, 2 Feb 2021 00:51:15 +0000 (01:51 +0100)]
accessibility/keyboard: Align the panelMenu button style
This get's rid of the single-indicator introduced in one of the latest
commits. This was causing the accessibility pill in the top panel
to have different padding from the keyboard layout pill.
Florian Müllner [Fri, 29 Jan 2021 19:33:23 +0000 (20:33 +0100)]
windowManager: Allow switching workspaces with super-scroll
So far, we couldn't allow workspace scrolling outside the overview
because scroll events were always sent to clients. However mutter
was changed recently to pass on scroll events when the mouse button
modifier (usually super) is pressed, which allows us to enable the
same workspace scrolling as in the overview now.
Florian Müllner [Fri, 29 Jan 2021 20:28:52 +0000 (21:28 +0100)]
swipeTracker: Optionally require modifiers for scrolling
The design now calls for super-scroll for workspace switching
in the session, however it is currently only possible for
SwipeTracker to either handle scroll events or not.
In order to support the new use case, add a new :scroll-modifiers
property that allows specifying modifiers for which scroll events
are handled.
projects / gnome-shell.git / log